home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8001 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: anvil.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Please Please Help! - pointer notation
  5. Date: 28 Feb 1996 16:17:34 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4h2rauINN90p@anvil.ugrad.cs.ubc.ca>
  8. References: <4gnlv9$1fh@news.mistral.co.uk> <4gtv05$45k@news.mistral.co.uk> <825462744snz@genesis.demon.co.uk>
  9. NNTP-Posting-Host: anvil.ugrad.cs.ubc.ca
  10.  
  11. In article <825462744snz@genesis.demon.co.uk>,
  12. Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
  13.  >In article <4gtv05$45k@news.mistral.co.uk>
  14.  >           mikebarnard@mistral.co.uk "Mike Barnard" writes:
  15.  >
  16.  >>And I had loads of e-mail replies this time. The answer was (as
  17.  >>always!) rather obvious, but I didn't realise that the absence of a
  18.  >>whitespace doesn't matter to the compiler.
  19.  >
  20.  >It does matter sometimes since some tokens are prefixes to other tokens,
  21.  >for example / and /* so
  22.  
  23. This ain't Fortran, after all.
  24.  
  25. The first Fortran compiler, completed after 18 person-years, began it's
  26. treacherous process by removing whitespace from the source. Hence, the
  27. statements
  28.  
  29.     DO I = 1,3        ( loop from 1 to 3 over variable I )
  30.  
  31. and
  32.     DOI = 1.3        ( assignment to variable DOI )
  33.  
  34. both became
  35.  
  36.     DOI=1,3        and     DOI=1.3
  37.  
  38. Since DOI is a valid identifier, the Fortran compiler could not decide whether
  39. to tokenize as DO I, or DOI until detecting the presence of the comma.
  40.  
  41.  >   a = b / *p;
  42.  >
  43.  >means something entirely different to
  44.  >
  45.  >   a = b /*p;
  46.  
  47. Not to mention:
  48.  
  49.     integer=3;        versus        int eger=3;
  50.  
  51.  >and consider what
  52.  >
  53.  >   x = y+++z;
  54.  
  55. Shoot. I was just perusing the ISO9899 in the library, but I forgot to check
  56. whether it actually specifies that the longest lexeme always takes precedence
  57. in the case of lexical ambiguity. Is this the case?
  58.  
  59.  >means. However in most cases there is no ambiguity and white-space makes
  60.  >no difference.
  61.  
  62. Are you implying that it _is_ ambiguous rather than equivalent to x = y++ +z?
  63. That would be rather unfortunate.
  64. -- 
  65.  
  66.